Transit Portal: Bringing Connectivity to the Cloud

Computing in the cloud is becoming more common as companies migrate their applications into cloud computing platforms to reduce maintenance costs and increase availability. Cloud hosting platforms, such as Amazon’s EC2, provide a virtual hosting environment that is easy for a service provider to provision in response to dynamically changing demands. This model lowers the barrier to entry for innovative Internet services and applications. In addition to hosting, services that are hosted in a cloud may also require a virtual networking environment to retain real-time, finegrain control over how traffic enters the cloud. For example, given the global nature of many Internet applications, cloud data centers can be in many diverse geographical locations; a cloud service could expose some of these connectivity options and let the service provider to decide how the traffic is routed into and out of the cloud, as well as across the cloud for that service. Various virtual network infrastructures (e.g., VINI) already allow researchers to instantiate networks and run simultaneous network experiments on the same infrastructure [1]. In addition to the virtual network infrastructure itself, however, cloud networks also need external connectivity. Today, cloud hosting platforms provide only limited options for such external connectivity; the standard method is to provide bulk upstream connectivity to every application that is hosted on the cloud. Certain hosted applications may, however, need more control over how traffic exits and enters the cloud via its external connections. For example, some cloud users might prefer to select upstream providers based on cost while others might focus on performance. Unfortunately, such flexibility is currently difficult to achieve. Cloud infrastructure providers try to balance performance and cost when it comes to their connections to the Internet, so customizing upstream connectivity for each service or virtual network in the cloud introduces prohibitive management and operational overhead, particularly if the service itself is short-lived or otherwise unstable. Virtual networks, on the other hand, face multiple hurdles if they want to peer directly with the Internet service providers, including: (1) negotiating direct contracts with the service providers, (2) obtaining IP addresses for proper peering with the ISPs, and (3) connecting the virtual network to the external legacy network. These challenges become even more significant when the virtual networks are short-lived (e.g., in the case of researchers running experiments, or a virtual network that is provisioned for a specific event). In these cases, negotiating upstream connectivity from ISPs, who prefer stable, predictable BGP sessions, may be inconvenient or simply untenable. Seattle Exchange Atlanta Exchange